home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-20 / nosvw.zip / NOSFILES.ZIP / FORWARD.DOC < prev    next >
Text File  |  1991-09-18  |  23KB  |  626 lines
  1. ===========                                         NOSview [137]
  2. FORWARD.DOC
  3. ===========
  4.  
  5. Introduction
  6. ------------
  7. This section of the NOS docs deals with the intricacies of mail
  8. forwarding.  You should read and understand this documentation
  9. thoroughly before attempting to forward mail through your NOS box
  10. to the AX.25 BBS world, otherwise you might grossly misconfigure
  11. your system and be the unhappy recipient of flames from BBS
  12. sysops.
  13.  
  14. This section does NOT deal with the minutiae of the mailbox and
  15. its various commands; it assumes that you understand concepts
  16. such as user areas (both public and private) and how to list and
  17. send mail. If you need help with these, please look elsewhere in
  18. the NOS docs.
  19.  
  20. Apart from the usual DOMAIN.TXT and other files necessary for
  21. ordinary functionality of NOS, three files are important in the
  22. mail forwarding process. These are: N:\SPOOL\FORWARD.BBS,
  23. N:\ALIAS and N:\SPOOL\REWRITE.  The contents of these will now be
  24. addressed individually.
  25.  
  26.  
  27. FORWARD.BBS
  28. -----------
  29. This file describes the actions taken by NOS in forwarding to
  30. AX.25 BBSs.  The file contains a series of forwarding records,
  31. each record being separated by a line containing two or more
  32. hyphens.  The template for a forwarding record is:
  33.  
  34. -----------------------------------------------------------------
  35. BBS callsign
  36. Connection route
  37. Connection commands                <zero or more lines>
  38. List of areas to be forwarded      <one per line>
  39. ------------                       <end of record>
  40. -----------------------------------------------------------------
  41.  
  42.  
  43. BBS callsign
  44. ------------
  45. This is simply the ordinary call of the remote BBS.  A typical
  46. (but not random!) entry might be simply the line:
  47.  
  48. -----------------------------------------------------------------
  49. sm0rgv
  50. -----------------------------------------------------------------
  51.  
  52. The callsign may be followed, on the same line, by a comma-
  53. separated list of valid intervals when forwarding is to take
  54. place.  Each valid interval is a four digit number: the first two
  55. digits are the beginning hour of the valid interval, the last two
  56. digits are the final hour of the valid interval.
  57.  
  58. For example, if the first line of a forwarding record looks like:
  59.  
  60. -----------------------------------------------------------------
  61. sm0rgv 0006,1414
  62. -----------------------------------------------------------------
  63.  
  64. then forwarding to sm0rgv will take place only during hours
  65. numbered 00, 01, 02, 03, 04, 05, 06 and 14.  Ticks of the mbox
  66. timer outside of these times will not cause mail to be forwarded
  67. to sm0rgv.  The default interval for forwarding is 0023.
  68.  
  69.  
  70. Connection route
  71. ----------------
  72. This is the method by which communication is to be established
  73. with the remote BBS.  The first token on the line is the type of
  74. protocol to be used.  This is one of ax25, netrom or tcp.
  75. Following this is whatever further information the chosen
  76. protocol requires to make the connection.
  77.  
  78. An example connection route for a simple ax25 connection on
  79. interface tnc0 is:
  80.  
  81. -----------------------------------------------------------------
  82. ax25 tnc0 g3dlh
  83. -----------------------------------------------------------------
  84.  
  85.  
  86. Connection commands
  87. -------------------
  88. Connection commands may, optionally, follow the connection route.
  89. These take the form of a dot (period), followed by the command
  90. which will be transmitted once the connection defined in the
  91. first line of the connection route is established.
  92.  
  93. For example, suppose that we wish to establish a NET/ROM
  94. connection with sm0rgv-2, through the netrom node #sth67. Then
  95. the connection route and connection command portion of the record
  96. would look like:
  97.  
  98. -----------------------------------------------------------------
  99. netrom #sth67
  100.  .c sm0rgv-2
  101. -----------------------------------------------------------------
  102.  
  103. Note that the dot would be placed at the beginning of the line;
  104. it is placed here indented by one column simply so that gateways
  105. which handle this message do not complain at having a line
  106. beginning with a full stop; this convention is followed
  107. throughout this documentation.
  108.  
  109. If the station is reached through digipeating, then the
  110. digipeater callsigns should be in the ax25 route to the
  111. destination callsign.  That is, if you wish to forward traffic to
  112. w0ljf, using k2na as a digipeater, then you should have the line:
  113.  
  114. -----------------------------------------------------------------
  115. ax25 route add w0ljf k2na
  116. -----------------------------------------------------------------
  117.  
  118. in AUTOEXEC.NOS.
  119.  
  120.  
  121. List of areas to be forwarded
  122. -----------------------------
  123. This is a list, one per line, of entries in the N:\SPOOL\MAIL
  124. directory which will be forwarded to the remote BBS.  An entry of
  125. the form:
  126.  
  127. -----------------------------------------------------------------
  128. callsign
  129. -----------------------------------------------------------------
  130.  
  131. will cause the file N:\SPOOL\MAIL\callsign.TXT to be scanned for
  132. unread messages.  Any such messages are sent to the remote BBS
  133. and deleted from the file.
  134.  
  135. One can also forward user areas using this mechanism.  To do
  136. this, simply place a line containing the name of the area in the
  137. record.  So, to forward amsat bulletins to the BBS, one would
  138. have a line:
  139.  
  140. -----------------------------------------------------------------
  141. amsat
  142. -----------------------------------------------------------------
  143.  
  144. This will search the N:\SPOOL\MAIL\AMSAT.TXT file; any messages
  145. contained therein which have not been forwarded to the BBS in
  146. question will be forwarded.  They will NOT be deleted.
  147.  
  148. The determining factor as to whether or not entries are deleted
  149. is that if the filename is present in the AREAS file, then there
  150. is NO deletion, otherwise there is.
  151.  
  152. Please note that ONLY files in N:\SPOOL\MAIL are checked.  In
  153. particular, the outbound SMTP mail queue is NOT checked.
  154.  
  155. Changing the recipient address
  156. ------------------------------
  157. Normally, NOS uses the information in the To: header line to
  158. determine the parameters used by the "S" command during BBS
  159. forwarding.  As the To: header is unchanged by all ALIAS and
  160. REWRITE machinations, the mail will be sent to the BBS addressed
  161. precisely as the originator of the message typed it.
  162.  
  163. Occasionally, one might want to change this behaviour.  In this
  164. case, a line of the form:
  165.  
  166. -----------------------------------------------------------------
  167. area  newaddress
  168. -----------------------------------------------------------------
  169.  
  170. in the list of areas to be forwarded will replace the originally
  171. typed destination with the string newaddress instead.
  172.  
  173.  
  174. ALIAS
  175. -----
  176. The alias file is used to map LOCAL names to other names, which
  177. may be either local or remote.  Additionally, from a single input
  178. message, the alias file permits one to produce multiple output
  179. messages.
  180.  
  181. Thus, typical uses for the ALIAS file are: converting one local
  182. name to another, converting a local name to a remote name, and
  183. exploding a mail message so that it is passed on to several
  184. recipients.
  185.  
  186. The format of a record in the alias file is very simple:
  187.  
  188. -----------------------------------------------------------------
  189. aliasname       recipient1 recipient2 recipient3
  190. <tab> or <SP>   recipient4 ... recipientN
  191. -----------------------------------------------------------------
  192.  
  193. There is no separation between records in the ALIAS file other
  194. than a newline.
  195.  
  196. The aliasname is a local username; that is, it does not contain
  197. an "@" symbol.  When the alias file is processed, if the
  198. destination of the message matches precisely the aliasname, then
  199. the mail is redirected to ALL of the aliased recipients.
  200.  
  201. Scanning of the ALIAS file is performed by the SMTP server.  The
  202. SMTP timer (which controls the SMTP client) is kicked whenever
  203. the mailbox or SMTP server queues something for delivery by SMTP.
  204.  
  205. Mail transport within a single NOS system is performed through
  206. the SMTP client/server mechanism.
  207.  
  208. The result of these facts is that as soon as a piece of mail is
  209. entered to the mailbox, the SMTP client is kicked and attempts to
  210. deliver the mail (which has already been scanned by the rewrite
  211. mechanism - see below).  If the mail is local to the NOS system
  212. (i.e. no "@" sign in the address), then the ALIAS file will be
  213. scanned and the name mappings take place.
  214.  
  215. A few lines in the ALIAS file might look something like:
  216.  
  217. -----------------------------------------------------------------
  218. bdale   bdale@n3eua
  219. local   fred@k0yum bdale@n3eua bill@ai0c.co.usa.na
  220.         n5op@n5op jim@k0jtz n0esg@n0esg
  221. g4bki   g4bki@gb7bil.2712.gbr.eu
  222. -----------------------------------------------------------------
  223.  
  224. The system must know how to deliver traffic to each of the
  225. individual addresses in the style in which they are entered in
  226. the ALIAS file.  If the system does not know how to deliver one
  227. of the new addresses, then it will send it to the SMTP gateway
  228. station defined by the 'smtp gateway' command.
  229.  
  230. Note that it is reasonable, and sometimes desirable, to have
  231. alias records of the form:
  232.  
  233. -----------------------------------------------------------------
  234. area    area dest1 dest2 ...
  235. -----------------------------------------------------------------
  236.  
  237. As the ALIAS file is scanned only once (see below), this does not
  238. result in an infinite recursion.
  239.  
  240.  
  241. REWRITE
  242. -------
  243. The rewrite file is used to perform a one-to-one mapping between
  244. destination addresses as received by NOS and destination
  245. addresses as actually used by NOS.
  246.  
  247. Each record within the rewrite file comprises a single line,
  248. containing either two or three entries separated by spaces.
  249.  
  250. The first field is the template field; if a destination address
  251. matches the template, it is replaced by the second field.
  252.  
  253. The third field, which is optional, is the single letter "r",
  254. which, if present, tells NOS to rescan the rewrite file, using
  255. the new destination address to attempt to match against the
  256. templates.
  257.  
  258. A template may contain asterisks.  These stand for a match of any
  259. number of characters (including zero).
  260.  
  261. In the second field, the character "$", followed by a single
  262. digit in the range 1 to 9, represents the string that matched the
  263. respective asterisk in the template.
  264.  
  265. By way of example, suppose that there is a line in the rewrite
  266. file which looks like:
  267.  
  268. -----------------------------------------------------------------
  269. *@* $1%$2@g1emm.ampr.org
  270. -----------------------------------------------------------------
  271.  
  272. Then, any traffic reaching the system through the mailbox or the
  273. SMTP server, but which is supposed to go to a remote system, will
  274. be redirected to go through g1emm.ampr.org.
  275.  
  276. Suppose that a user logs on, and sends a message to n0gbe@nq0i.
  277. Then the rewrite file attempts to match "n0gbe@nq0i" against the
  278. entry *@*.  It matches, and assignes $1 the value n0gbe, and $2
  279. the value nq0i.
  280.  
  281. The mail file as written to the disk will no longer be to
  282. n0gbe@nq0i, but, rather, to n0gbe%nq0i@g1emm.ampr.org.  [The
  283. nomenclature "station1%station2@station3" means the final
  284. destination is station1@station2, and this traffic is to be
  285. routed through the gateway station3].
  286.  
  287. As soon as a template match is found, the conversion is performed
  288. and scanning is stopped, unless the third "r" field is present,
  289. in which case scanning restarts from the top of the file.
  290.  
  291. N.B. It is a good idea to have a line of the form:
  292.  
  293. -----------------------------------------------------------------
  294. *@*.ampr.org $1@$2.ampr.org
  295. -----------------------------------------------------------------
  296.  
  297. at the beginning of your rewrite file.  This will cause all
  298. amprnet traffic to be caught early in the rewrite scan, and no
  299. further scanning (and, hence, no unexpected substitutions) will
  300. take place.
  301.  
  302.  
  303. Scanning procedure
  304. ------------------
  305. The two files which are used to determine the disposition of
  306. traffic are scanned under slightly different circumstances.  Note
  307. that neither the ALIAS nor the REWRITE scan makes any actual
  308. changes to the contents of the traffic.  In particular, the To:
  309. field remains exactly as it was first entered into the system.
  310.  
  311. There are four possible entry routes for traffic into the system:
  312.  
  313. 1.  SMTP
  314. 2.  through the mailbox by a user
  315. 3.  through the mailbox by a BBS
  316. 4.  via an external program (like BM) or creation of the files
  317.     manually.
  318.  
  319. NOS determines if a piece of traffic was entered into the system
  320. by a BBS by looking for a BBS system ID (like the "[NET-H$]"
  321. block issued by NOS) on the incoming connection prior to messages
  322. being uploaded.
  323.  
  324.  
  325. Traffic received by SMTP server
  326. -------------------------------
  327. 1.  The rewrite file is scanned and any changes applied (unless
  328. the traffic was received through the local mailbox; in that case,
  329. this step does not occur);
  330.  
  331. 2. If the traffic appears to be local then the alias file is
  332. scanned and any changes or explosions applied.
  333.  
  334. 3. Any copies local to the system are delivered; copies for
  335. remote delivery are placed in the SMTP queue.
  336.  
  337.  
  338. Traffic received by mailbox from user
  339. -------------------------------------
  340. 1. The rewrite file is scanned and any changes applied;
  341.  
  342. 2. The traffic is passed to the SMTP client.
  343.  
  344.  
  345. Traffic received by mailbox from BBS
  346. ------------------------------------
  347. 1. The rewrite file is scanned and any changes applied;
  348.  
  349. 2. The traffic is passed to the SMTP client.
  350.  
  351.  
  352. Traffic entered by external mechanism
  353. -------------------------------------
  354. 1. No scanning occurs;
  355.  
  356. 2. The traffic is passed to the SMTP client.
  357.  
  358.  
  359. Headers
  360. -------
  361. Appropriate RFC-822 headers are added to all incoming traffic.
  362. Traffic entering through the mailbox receives a full complement
  363. of RFC-822 headers; traffic coming through the SMTP server has
  364. only a "Received:" header applied.
  365.  
  366. On forwarding to a BBS, if an item of traffic contains BBS R:
  367. headers, the RFC-822 header is converted to an appropriate R:
  368. line at the time that NOS forwards the message. (This change only
  369. occurs for BBS forwarding; forwarding by SMTP retains the RFC-822
  370. headers).
  371.  
  372.  
  373. Bulletin Identifiers (BIDs)
  374. ---------------------------
  375. The AX.25 BBS system has evolved a reasonably efficient way of
  376. reducing overhead when forwarding bulletins.  When a bulletin is
  377. originated on a BBS, it is given a unique bulletin identifier
  378. (BID).  This BID should (theoretically) travel with the bulletin,
  379. and should never be changed during the distribution of the
  380. bulletin.
  381.  
  382. Each system keeps track of all received BIDs.  If a forwarding
  383. station wishes to forward a bulletin to a BBS, then the receiving
  384. station checks its local list of known BIDs and informs the
  385. transmitting station if it already possesses the bulletin in
  386. question.
  387.  
  388. The NOS mailbox conforms to this protocol.  Received BIDs are
  389. stored in the file N:\SPOOL\HISTORY, and are encoded in the
  390. Message-ID: header line of the message by NOS.  Messages
  391. forwarded from areas listed in the AREAS file will have their BID
  392. (re)generated from the Message-ID: line.
  393.  
  394. Note that ALL messages from public areas are forwarded with a
  395. BID, whether or not the message was produced with the "SB"
  396. command.
  397.  
  398. Like other BBSes, NOS will inform a transmitting station not to
  399. transmit a bulletin if it is one that NOS already has locally;
  400. likewise, it understands similar messages from other stations to
  401. which it tries to forward.
  402.  
  403. Note that the BID mechanism is not a part of the SMTP world.  If
  404. you are forwarding bulletins through SMTP, there is no mechanism
  405. by which the receiving station can reject the attempted delivery
  406. of a bulletin, even if it already exists on the recipient system.
  407.  
  408. (Note that a possible workaround is to deliver bulletins to
  409. TCP/IP stations using TCP instead of SMTP.  Alternatively, one
  410. could use NNTP, as NNTP commands utilise the Message-ID: line,
  411. from which the BID is derived.)  The BID is preserved no matter
  412. which mechanism is used to deliver the bulletin.
  413.  
  414. Traffic in practice
  415. -------------------
  416. Now, the big question is, how does one set up these various files
  417. to perform intelligent manipulation of mail?  A number of
  418. examples follow.  Note that, often, there is more than one way to
  419. accomplish an objective.  The following are merely examples (and
  420. not necessarily the most efficient method possible for any given
  421. case).
  422.  
  423. The format used will be:
  424.  
  425. -----------------------------------------------------------------
  426. typed destination -> intended destination
  427. -----------------------------------------------------------------
  428.  
  429. followed by the necessary entries in the ALIAS, REWRITE and
  430. FORWARD.BBS files.
  431.  
  432.  
  433. Using familiar names - SMTP destination
  434. -----------------------------------------------------------------
  435. bdale -> bdale@n3eua.ampr.org
  436.  
  437. alias:
  438. bdale   bdale@n3eua.ampr.org
  439.  
  440. rewrite:
  441. forward:
  442. -----------------------------------------------------------------
  443.  
  444.  
  445. Exploding local mail
  446. -----------------------------------------------------------------
  447. sysops -> nq0i, n5op@n5op.ampr.org
  448.  
  449. alias:
  450. sysops  nq0i n5op@n5op@ampr.org
  451.  
  452. rewrite:
  453. forward:
  454. -----------------------------------------------------------------
  455.  
  456.  
  457. Using familiar names - BBS forwarding
  458. -----------------------------------------------------------------
  459. g4bki -> g4bki@gb7bil.2712.gbr.eu, to be forwarded by ai0c
  460.  
  461. alias:
  462. rewrite:
  463. forward:
  464. ai0c
  465. ax25 ax1 ai0c
  466. g4bki g4bki@gb7bil.2712.gbr.eu
  467. ai0c
  468. -----------------------------------------------------------------
  469.  
  470.  
  471. Handling incoming bulletins by subject
  472. -----------------------------------------------------------------
  473. tcpip@* -> nq0i, tcpip, bdale@n3eua.ampr.org, ai0c@ai0c [a BBS]
  474.  
  475. alias:
  476. tcpip   nq0i tcpip bdale@n3eua.ampr.org ai0c
  477.  
  478. rewrite:
  479. tcpip@* tcpip
  480.  
  481. forward:
  482. ai0c
  483. ax25 ai0c
  484. ai0c
  485. -----------------------------------------------------------------
  486.  
  487. Let's walk through the above example.  An incoming item comes in
  488. addressed to TCPIP@ALLUS.  A scan is made through the REWRITE
  489. file, and a match is found.  The item is redirected to tcpip.
  490. The ALIAS file is scanned; a total of four copies of the item
  491. exist after this, three in local areas tcpip, nq0i and ai0c, and
  492. one on the SMTP queue (for bdale@n3eua.ampr.org).  When the
  493. mailbox timer next ticks, the mail in the local ai0c area will be
  494. forwarded on the ax1 interface to ai0c.
  495.  
  496.  
  497. Routing based on Hierarchical addressing
  498. -----------------------------------------------------------------
  499. Wyoming -> KE7VS (SMTP)
  500. Nebraska -> AG0N (BBS over the NETROM, NETROM ID WNBBS)
  501. Europe -> W0LJF (BBS over AX.25)
  502.  
  503. alias:
  504. rewrite:
  505. *.noam            $1.na r
  506. *.us              $1.usa.na r
  507. *.usa             $1.usa.na r
  508.  
  509. *.ne              $1.ne.usa.na r
  510. *.wy              $1.wy.usa.na r
  511.  
  512. *@*.*.wy.usa.na   $1%$2.$3.wy.usa.na@ke7vs
  513. *@*.wy.usa.na     $1%$2.wy.usa.na@ke7vs
  514.  
  515. *.ne.usa.na     ag0n
  516. *.eu            w0ljf
  517.  
  518. forward:
  519. ag0n
  520. netrom tnc0 wnbbs
  521. ag0n
  522. ----------
  523. w0ljf
  524. ax25 ax1 w0ljf
  525. w0ljf
  526. ----------
  527. -----------------------------------------------------------------
  528.  
  529. Why is the example REWRITE file apparently so complicated?  This
  530. is to handle poorly constructed hierarchical addresses in a
  531. reasonable way.
  532.  
  533. A full US hierarchical address has the form:
  534.  
  535.              callsign@BBS.#localid.state.usa.na.
  536.  
  537. Many states have no #localid field.  In the example REWRITE file
  538. above, the first three lines convert non-standard, but frequently
  539. used, US designators to the more standard format.
  540.  
  541. It is common for users not to use a full hierarchical address if
  542. the destination is relatively local.  For example, a user might
  543. easily use only .wy instead of the full .wy.usa.na if he is
  544. geographically close to Wyoming.
  545.  
  546. The second grouping of two lines handles this problem.  Note the
  547. third, "r", field in all the entries so far.
  548.  
  549. The remainder of the file handles properly formatted hierarchical
  550. addresses.  The two Wyoming entries handle the cases with and
  551. without a #localid field.  Differentiation between these cases is
  552. not necessary for BBS forwarding.
  553.  
  554.  
  555. General bulletin handling
  556. -------------------------
  557. The details of bulletin handling will vary somewhat from place to
  558. place, as there are several distinct styles of bulletin handling
  559. currently in use in the AX.25 BBS world.  In general, it is
  560. necessary to arrange one's system so that it accepts bulletins
  561. from BBSes, forwards them to one or more stations, and also
  562. handles intelligently bulletins input by users into NOS.
  563.  
  564. Suppose that we wish to handle bulletins @JUNK.  We are to
  565. deposit them locally in the junk area, and also forward to BBS
  566. g4bki.  We also know that we generally receive @JUNK bulletins
  567. from g4amj, a local BBS which handles much bulletin traffic.
  568.  
  569. -----------------------------------------------------------------
  570. alias:
  571. rewrite:
  572. *@junk   junk
  573. forward:
  574. g4bki
  575. ax25 ax1 g4bki
  576. g4bki
  577. junk
  578. ----------
  579. g4amj
  580. ax25 ax1 g4amj
  581. g4amj
  582. junk
  583. ----------
  584. -----------------------------------------------------------------
  585.  
  586. All incoming @JUNK traffic is written to the junk area (which
  587. should be an explicit entry in the AREAS).
  588.  
  589. Each tick of the mailbox timer, NOS scans the junk area for
  590. traffic not forwarded to g4bki or g4amj and attempts to deliver
  591. unforwarded bulletins.  Usually, g4amj will respond with a "Have
  592. it" message and the bulletin will not be forwarded.  Any
  593. bulletins @JUNK deposited locally by users will automatically be
  594. sent to both g4bki and g4amj.
  595.  
  596.  
  597. Questions and Answers
  598. ---------------------
  599. Q.  Under what circumstances does NOS request reverse forwarding
  600. from a BBS?
  601.  
  602. A.  NOS requests a reverse forward after completing any forwards
  603. of its own to the BBS.  If no traffic was queued for a given BBS,
  604. then no connection is attempted, so no reverse forward request is
  605. issued.
  606.  
  607.  
  608. Q.  What kinds of message types does the NOS mbox support?
  609.  
  610. A.  Basically, NOS supports all two letter commands starting with
  611. an "S".  If the mailbox has not received an SID banner (the
  612. "[NET-H$]") from a connected station, then an SF command will
  613. send a followup to the address specified on the command line.
  614.  
  615. The SR command will send a reply to the current message. One can
  616. also issue the command "SR <number>", where <number> is the
  617. number of the message to which you want to generate a reply.
  618.  
  619. All other variations cause an X-BBS-Msg-Type: header to be added
  620. to the message.  When a message with such a line is forwarded to
  621. a BBS, it is sent to the BBS with the appropriate message type as
  622. the second letter in the "S" command to the BBS.
  623.  
  624. If NOS has received a valid SID, then ALL S commands are handled
  625. by the X-BBS-Msg-Type: mechanism outlined above.
  626.